


# 面试经验：
# 1. 有领导跟随的面试， 纯技术官问的问题不会特别难，因为未来可能成为同事，但是也不能明显放水
# 2. 二面官，需要问的问题 是技术官没闻到的，但是还有问的平淡无奇，还要有点水准
# 3. 主审官，它才是最终决定你是否入局的人，对待他一定要慎重，有可能小小的不起眼的失误就导致整场面试失败

# 总体讲，同事面一般都不会下狠手
# 面试过程包括入职后能低调必须低调，不仅决定了你面试是否通过，还决定了你入职后的任务安排等



# 1. 承受的 并发数
# 2. 有没有遇到生产上的问题，解决方案
# 3. 准备一个合理的自我介绍



# 还差准备的： 自我介绍 ， 

# 熟悉常见数据结构, 算法;

# Jenkins/Docker

# Django、FastAPI  

# 1. 承受的 并发数
# 2. 有没有遇到生产上的问题，解决方案
# 3. 准备一个合理的自我介绍


# 已经存在了django，学习了fastapi
# 工作年限
# 职业生涯 2家
# 项目经理 
# 技能于能力
# 在项目开发的过程中没有遇到什么特别难以解决的问题，整个开发过程中还算比较顺畅，
# 但是在项目开发过程中遇到过比较有意思的场景，比如：。。。。
# 知识点总结，就是都会哪些
# 现看一些算法题，
# 常用的算法，加上一些算法题
# 早上把准备的知识过一遍
# 公司在准备剩下的



# 自我介绍：
# 老师好，我叫沈聪，毕业于郑州大学，从毕业到目前就职于2家公司
# 分别是北京火谷网络这家公司主营业务时手机游戏产品，第二家公司是北京视野数科
# 这家公司主营业务时大数据服务，我在这家公司主要做服务器端开发相关工作，
# 我在这家公司工作包括对现有系统的维护和优化，对新技术调研学习后介绍给其他同事共同学习，
# 以提升公司后台程序的处理速度增强客户的体验，再就是解决一些生产问题，
# 我参过调研的技术包括大数据相关的如spark，数据库相关的如nebula数据库，
# 阿里平台相关的如dataphin、emr，自然语言处理相关的如 hanlp这是个自然语言处理库，
# 目前比较常用的开发语言包括 c c++ python
# 在工作用到的数据包括 mysql， redis， es，mq，nginx
# 了解的网络框架包括 django，fastapi，
# 大数据相关的如 datax sqoop spark kafka flink hive hadoop
# 工作上没用到的只是我自己平时感兴趣学习了解了一些开源项目
# 如网络相关的 muduo库 c++ 的boost库，nginx 模块开发，iouring，dpdk，还有一些其他的
# 对于开发语言相关的 如 c++ 11，模板泛型，元编程，
# python的魔法函数，抽象类，迭代器生成器，装饰器，元类编程，网络编程，异步这些
# mysql，常见语句优化思想，索引相关，MVCC，主从复制binlog，分库分表这些
# redis，5种数据结构，常用的场景，了解es常用的查询语句
# django 请求流程 orm ，如一对多，多对多，prefatch_relation，多对一，一对一的 select_relation，foreignkey
# only defer，序列化，反序列化，unittest测试
# fastapi，请求流程，依赖注入基本原理，pydantic ，和 starlettet
# 大数据处理相关的，离线数据处理，实时的流批一体，数据拉取，计算，数仓优化这些



# 自我介绍：
# 老师好，我叫沈聪，毕业于郑州大学，从毕业到目前就职于2家公司
# 分别是北京火谷网络这家公司主营业务时手机游戏产品，第二家公司是北京视野数科
# 这家公司主营业务时大数据服务，我在这家公司主要做服务器端开发相关工作，
# 我在这家公司工作 ,后端开发，主要语言是python，
# 用到了一中间件，如关系mysql， 缓存数据库redis，图数据库nebula， 分布式任务调度celery，rabbitmq，es
# 工作中经常会做大数据相关的，离线数据处理，涉及到了 hive sqark，datax一整条数据处理技术栈
# 数据分析相关的库 pandas numpy 等
# 尽量一年，随着ai快速发展，公司也有一些打磨想相关的，业务探索，我也学习了一些打磨想相关的技术


# 包括对现有系统的维护和优化，对新技术调研学习后介绍给其他同事共同学习，
# 以提升公司后台程序的处理速度增强客户的体验，再就是解决一些生产问题，
# 我参过调研的技术包括大数据相关的如spark，数据库相关的如nebula数据库，
# 阿里平台相关的如dataphin、emr，自然语言处理相关的如 hanlp这是个自然语言处理库，
# 目前比较常用的开发语言包括 c c++ python
# 在工作用到的数据包括 mysql， redis， es，mq，nginx
# 了解的网络框架包括 django，fastapi，
# 大数据相关的如 datax sqoop spark kafka flink hive hadoop
# 工作上没用到的只是我自己平时感兴趣学习了解了一些开源项目
# 如网络相关的 muduo库 c++ 的boost库，nginx 模块开发，iouring，dpdk，还有一些其他的
# 对于开发语言相关的 如 c++ 11，模板泛型，元编程，
# python的魔法函数，抽象类，迭代器生成器，装饰器，元类编程，网络编程，异步这些
# mysql，常见语句优化思想，索引相关，MVCC，主从复制binlog，分库分表这些
# redis，5种数据结构，常用的场景，了解es常用的查询语句
# django 请求流程 orm ，如一对多，多对多，prefatch_relation，多对一，一对一的 select_relation，foreignkey
# only defer，序列化，反序列化，unittest测试
# fastapi，请求流程，依赖注入基本原理，pydantic ，和 starlettet
# 大数据处理相关的，离线数据处理，实时的流批一体，数据拉取，计算，数仓优化这些






# mysql 的语句优化和  索引相关
# 分析sql语句，原则是只查询需要的数据，尽量不用子查询，join的时候使用小表驱动大表，使用联合查询替换 in 和not in
# 索引包括 主见索引，唯一索引， 单列索引 还有组合索引，索引的维护是需要占用空间的，对于频繁修改的字段不适宜加索引
# 索引使用与 where ， group by  order by，经常查询少有修改的字段，修改较多的字段不适宜加索引，遵循最左匹配原则，
# 注意索引失效，左模糊查询，索引参与计算、隐士类型转换，出现 or in这些，最好的就是覆盖索引这样能避免回表

# 索引下推：
# 传统的查询是根据索引查询满足索引最左前缀匹配的原则，返回给mysql服务层，然后服务层再根据后置条件对数据进行过滤
# 索引下推是将where中的所有所有包含索引的列下推到存储引擎层，存储引擎不仅根据索引条件进行匹配，还根据索引进行过滤
# 最后只将复合条件的数据返回给服务层，这样显著减少了需要回表读取完整数据的行数，
# 也减少了传输到服务器层的数据量，降低了服务器层的过滤负担


# python 抽象类：
# 实现接口多态，和多重继承约束；子类需实现多个抽象基类的方法（如Flyable和Swimmable），避免接口遗漏
# 在插件系统中，抽象类（如ImageProcessor）定义核心方法（process()），子类实现具体逻辑，扩展性强

# 元类
# 元编程允许在运行时创建或修改类结构，提升代码灵活性
# 类的工厂：继承type，重写__new__或__init__，控制类的创建过程
# 动态注入方法：通过元类为类添加通用方法（如日志记录）
# 自动添加属性 . 强制方法，动态映射数据库表到类属性
# 反射机制
# 动态属性管理：getattr/setattr：运行时获取或设置属性；hasattr/delattr：检查或删除属性
# 使用
# 单例模式：元类控制实例创建，确保全局唯一性
# ORM框架：动态生成数据库表对应的类



# 异步编程通过协程非阻塞执行I/O操作，提升吞吐量
# 核心组
# 事件循环（Event Loop）：调度协程的执行，监听I/O事件。
# 协程（Coroutine）：使用async def定义，通过await挂起耗时操作（如网络请求）。
# 任务（Task）：asyncio.create_task()包装协程，并发执行
# 并发控制：信号量（Semaphore）限制最大并发数


# 网络相关问题
# 模型相关的问题
# rtc相关的问题-
# 准备一下kafka
# python高级问题


# 进程 (Process):
# 定义: 操作系统资源分配和调度的基本单位。每个进程拥有独立的虚拟地址空间（代码、数据、堆、栈）、文件描述符、环境变量、安全属性等。
#         一个进程崩溃通常不会直接影响其他进程。
# 隔离性: 高（内存隔离是其核心特性）。
# 开销: 创建、销毁、上下文切换开销最大（涉及内存空间、页表、文件描述符表等的切换）。
# 通信: 进程间通信 (IPC) 机制复杂且相对慢（如管道、消息队列、共享内存、信号量、Socket等）。
# 并行性: 可以利用多核CPU实现真正的并行。
# 适用场景
# 需要高安全性和隔离性的任务: 浏览器不同标签页/插件、安全沙箱、数据库服务器进程池。
# 需要利用多核并行计算的独立任务: 科学计算、大规模数据处理（MapReduce类任务）。
# 运行第三方或不可信代码: 将其隔离在独立进程中。
# 需要独立崩溃恢复的组件: 如Web服务器的主进程和工作进程（如Nginx, Gunicorn prefork）。
# 系统守护进程: 长期运行的后台服务。
# 不适用场景
# 需要频繁创建销毁大量执行单元的场景: 开销过大（如处理海量短连接请求）。
# 需要极低延迟通信和共享大量数据的紧密协作任务: IPC通信成本高。
# 资源受限的环境: 每个进程都有固定的内存开销。





# 线程 (Thread):
# 定义: 操作系统能够进行运算调度的最小单位。它是进程中的一个执行流。
#     同一个进程内的所有线程共享该进程的内存空间（代码段、数据段、堆、打开的文件等），
#     但每个线程拥有自己独立的栈和寄存器状态。
# 隔离性: 低（共享内存空间，一个线程崩溃可能导致整个进程崩溃）。
# 开销: 创建、销毁、上下文切换开销比进程小很多（主要涉及栈指针、寄存器等，不切换内存空间）。
# 通信: 线程间通信非常方便快捷（通过共享内存），
#     但也因此需要复杂的同步机制（如互斥锁、信号量、条件变量等）来避免数据竞争和死锁。
# 并行性: 可以利用多核CPU实现真正的并行（一个进程内的多个线程可以在不同核心上同时运行）。
# 适用场景
# 需要响应式用户界面的程序 (GUI): 主线程处理UI事件，后台线程执行耗时操作（如下载、计算）避免界面卡顿。
# 高性能服务器处理并发连接: Web服务器（如Tomcat线程池）、游戏服务器、数据库连接池。一个连接一个线程（或线程池处理）。
# 需要利用多核加速的计算密集型任务 (需精细同步): 图像/视频处理、物理模拟（任务可分解且需要共享中间数据）。
# 后台任务执行: 日志记录、定时任务、监控等。
# 不适用场景
# 需要极高并发连接数 (C10K, C100K问题): 即使使用线程池，大量线程的上下文切换开销和内存占用（每个线程栈）会成为瓶颈。
# 任务间通信和同步极其复杂的场景: 容易陷入死锁、数据竞争的泥潭，调试困难。
# 对稳定性要求极高的核心服务: 一个线程的崩溃可能拖垮整个服务。
# 单核CPU上的纯计算密集型任务: 线程切换反而增加开销，不如顺序执行。





# 协程 (Coroutine):
# 定义: 一种用户态的轻量级线程。不由操作系统内核调度，而是由程序员在用户空间显式控制调度（协作式调度）。
#     协程拥有自己的寄存器上下文和栈，在挂起时保存上下文，恢复时恢复上下文。
# 隔离性: 最低（通常运行在同一个线程内，共享该线程的所有资源）。
# 开销: 创建、销毁、上下文切换开销最小（通常只是保存/恢复少量寄存器，不涉及内核态切换）。
# 通信: 通信方式类似线程（共享内存），也需要同步机制，但由于通常在单线程内协作运行，同步需求可能简化。
# 并行性: 本身不提供并行性（一个线程内同一时刻只有一个协程在执行）。
#         需要配合多线程或多进程才能利用多核（例如，一个线程运行多个协程，多个线程各自运行多个协程）。
# 适用场景
# 高并发I/O密集型服务: 最佳场景。Web服务器（Go, Python asyncio, Node.js）、API网关、微服务、实时通信（聊天、推送）、爬虫。
#     单线程内可轻松支撑成千上万协程处理网络连接。
# 需要高效处理大量阻塞操作的场景: 如大量数据库查询、文件读写、网络请求（协程在等待I/O时挂起，让出CPU给其他协程）。
# 状态机或生成器: 协程天然适合实现需要保存中间状态的操作，如生成器（yield）、解析器。
# 简化异步回调代码: 用同步代码风格写异步逻辑（async/await）。
# 不适用场景
# 纯计算密集型任务 (CPU Bound): 协程本身不提供并行能力。在一个线程内运行计算密集型协程，无法利用多核，且协作式调度在计算时不会主动让出CPU，可能导致其他协程“饿死”。（需配合多线程使用）。
# 需要利用操作系统原生线程特性的场景: 如需要将执行单元绑定到特定CPU核心、使用依赖于特定线程本地存储(TLS)的库。
# 需要长时间占用CPU而不进行I/O操作的任务: 会阻塞同线程内所有其他协程（违背协作式原则）。
# 涉及阻塞式系统调用且无法异步化的操作: 会阻塞整个线程。需要底层I/O库支持非阻塞/异步操作（如epoll, kqueue, IOCP配合协程库）。



# 总结与选择建议
# 选进程： 当你需要最高级别的隔离性、安全性、稳定性，或者任务本身是独立、重量级、需要并行且不频繁通信。代价是开销最大。
# 选线程： 当你需要利用多核并行处理任务，且任务间需要高效共享内存数据（尽管同步复杂），
#       并且并发量（线程数）不是极端巨大（如几百几千）。适合计算密集或混合型任务。
# 选协程： 当你需要处理海量并发I/O操作（网络、磁盘），追求极高的吞吐量和资源利用率（单机支撑数万甚至百万连接），
#       能够接受协作式调度模型和用户态调度的复杂性。是解决C10K+问题的利器。对于CPU密集型部分，通常需要结合线程池使用。


# 现代趋势： 在高并发网络服务领域，协程（配合事件循环和非阻塞I/O）因其极高的资源利用率和并发能力，
# 已成为主流解决方案（Go语言的goroutine是杰出代表）。
# 线程和进程则在需要更强隔离、利用多核并行计算或运行独立组件时继续发挥重要作用。
# 实践中常常是混合使用：例如，用多进程利用多核并增强稳定性，每个进程内用多线程处理并行计算或管理资源，
# 每个线程内用协程处理高并发I/O。















# --------------------------------------------------------
# 特性	   TCP (传输控制协议)	                                         UDP (用户数据报协议)
# 连接方式	面向连接 (Connection-Oriented)	                                无连接 (Connectionless)
# 可靠性	   高可靠。确保数据按序、完整、无差错地到达。	                         不可靠。不保证数据到达、顺序或完整性。
# 传输方式	字节流 (Byte Stream)。数据被视为连续的字节流。	              数据报 (Datagram)。数据以独立的数据包发送。
# 流量控制	有。防止发送方淹没接收方。	                                  无。发送方尽可能快地发送。
# 拥塞控制	有。检测网络拥塞并调整发送速率。	                          无。不主动避免或适应网络拥塞。
# 速度	   较慢。建立连接、确认、重传、控制机制带来开销。	                  非常快。几乎没有协议本身的开销。
# 头部大小	较大 (通常 20 字节 + 选项)。包含丰富控制信息。                	较小 (固定 8 字节)。信息简单。
# 数据顺序	保证 数据按发送顺序到达。	                                  不保证 数据报到达的顺序。
# 错误检查	有。通过校验和检测错误，并通过重传修复。	                 有 (校验和)，但检测到错误的数据报直接被丢弃，不重传。
# 应用场景	要求高可靠性的应用：                                         要求低延迟、能容忍少量丢失的应用： 
#             Web (HTTP/1, HTTP/2), Email (SMTP, POP3, IMAP),            实时音视频 (VoIP, 视频会议, 直播), 在线游戏,
#             文件传输 (FTP), 远程登录 (SSH, Telnet), 数据库访问等。	       DNS 查询, SNMP, DHCP, TFTP, QUIC (HTTP/3的底层) 等。

# TCP:需要可靠传输;  UDP:需要速度/实时性，容忍丢包

# tcp性能开销： 连接建立/断开 (三次握手/四次挥手)、确认、重传、流量/拥塞控制机制都带来额外开销和延迟。
#       服务器需要维护每个 TCP 连接的状态信息 (TCB)，高并发时消耗大量内存和 CPU，
#       移动网络适应性： 在移动网络（IP 切换频繁）中，TCP 连接容易中断，需要重建，增加延迟


# UDP问题:
# 不可靠性： 数据可能丢失、重复、乱序。应用层必须自己处理这些问题（如果需要可靠性），
#           例如实现超时重传、确认机制、数据排序等。这增加了应用开发的复杂性。
# 无拥塞控制： 如果应用发送过快，会加剧网络拥塞，导致自己和他人性能都下降。应用层有责任实现合理的发送速率控制。
# 数据报大小限制： 需考虑路径 MTU，避免 IP 



# QUIC 通过 ​​UDP 封装​​、​​0-RTT 连接​​、​​流级多路复用​​及​​内置加密​​，重构了传输层协议的核心能力，
# 成为 HTTP/3 时代的基础设施。其设计直指 TCP 的延迟、阻塞与迁移痛点，
# 在移动互联网、实时交互与边缘计算场景中展现出显著优势。尽管面临部署成本与兼容性挑战，
# QUIC 的标准化与生态成熟将推动其成为下一代互联网的传输层标准

# 握手：快速连接建立
# 0-RTT握手：对于之前连接过的服务器，QUIC可以在第一个数据包中就发送应用数据
# 1-RTT握手：对于新连接，QUIC通常只需要一次往返即可完成握手

# 连接迁移：QUIC使用连接ID而非IP地址和端口来标识连接，允许客户端在切换网络(如WiFi到4G)时保持连接。

# 优点：
# 更快的连接建立
# 更好的移动网络性能
# 改进的多路复用
# 内置安全性
# 连接迁移能力

# 缺点：
# UDP可能被某些网络限制
# CPU消耗较高(由于加密计算)
# 协议较新，支持度仍在增长


# quic结合 rtc
# 信令服务器（如SDP交换）：传统信令多用HTTP/WebSocket（基于TCP），QUIC可降低连接建立延迟。
# 优势：更快建立会话，提升用户体验（如会议加入速度）。


# 混合使用场景
# 音视频流：仍用UDP+WebRTC（追求最低延迟）。  牺牲少许准确，提升更好的体验
# 数据通道（如聊天、文件共享）：通过QUIC传输，确保可靠性。


# webrtc：通过一系列创新技术弥补了 UDP 本身的不可靠性缺陷，同时最大化保留了其低延迟优势
# 连通性：解决 NAT/防火墙穿透问题，建立最优传输路径（STUN, TURN）
# DTLS-SRTP (双加密层)
# 先通过 DTLS 握手建立安全通道（基于 UDP 的 TLS）。（DTLS 支持 0-RTT 恢复会话）
# 再使用 SRTP 加密媒体流，防止中间人攻击。

# 重传策略：NACK
# 接收方检测丢包后发送 NACK 报文请求重传。
# 仅重传关键包（如 RTP 序列号缺失部分），非全部数据



# WebRTC 的前向纠错（Forward Error Correction, FEC）是一种通过在传输数据时添加冗余信息来对抗网络丢包的技术。
# 它允许接收方在部分数据丢失时，无需重传即可恢复原始数据，从而降低延迟并提升实时通信的可靠性。
# 以下是其核心原理、实现方式和应用场景的详细介绍：

# ​​XOR-based FEC​​：对一组数据包进行异或运算生成冗余包（简单但抗连续丢包能力弱）。
# 原始包: [P1][P2][P3]  
# FEC 包: F1 = P1 XOR P2 XOR P3  丢失 P2，接收端可通过 P1 XOR P3 XOR F1 恢复 P2
# f1 = 1 ^ 2 ^ 3  ==推导==>  2 = f1 ^ 1 ^ 3  形同值异或=0
# ​​实际发送的包序列​​：[P1][P2][P3][F1]（注：F1 可能延迟发送以优化带宽）

# ​​恢复步骤​​：
# ​​检测丢包​​：通过 RTP 序列号发现 P2 缺失。
# ​​验证 F1 覆盖范围​​：检查 F1 的头部字段（mask）确认其保护 P1, P2, P3。
# 计算丢失的 P2​​： P2 = P1 XOR P3 XOR F1
# ​​恢复结果​​：若 P1 和 P3 未损坏，P2 可被完美恢复。


# 边界情况处理​​
# ​​多包丢失​​：若 P2 和 P3 同时丢失，仅靠 F1 无法恢复（需更多冗余包）。
# ​​FEC 包丢失​​：若 F1 丢失，只能依赖重传（如 NACK）。
# ​​动态分组调整​​：WebRTC 可能根据网络状况动态调整组大小（如从 3 包改为 5 包 + 2 FEC 包）


# 应用场景​​
# ​​实时视频/音频通话​​：对抗突发丢包，避免重传延迟。
# ​​屏幕共享​​：保护关键帧（如 I 帧）的完整性。
# ​​弱网环境​​：在丢包率高的移动网络中维持流畅性。


# 技术	        原理	        延迟	        带宽开销	        适用场景
# ​​FEC​​	    预先发送冗余	    低	              中	            随机丢包
# ​​NACK​​	   丢包后重传	        中	              低	           低丢包率环境
# ​​ARQ​​	    确认重传	        高	              低	           非实时传输
# ​​PLC​​	  丢包隐藏（如插帧）	最低	           无	            小规模丢包




# 对你简历上的项目（尤其是那个终极目标项目）要了如指掌，能清晰阐述架构设计、技术选型理由、遇到的挑战（特别是性能瓶颈、稳定性问题）、如何解决、优化效果、权衡取舍。


# 性能分析相关工具：
# cpu：
# 内存：
# 磁盘、IO：